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PRE-APPEAL BRIEF REQUEST FOR REVIEW 

Mail Stop AF 
Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 

Dear Sir: 

Applicants respectfully request a Pre- Appeal Brief Review of the final rejection in the 
above-identified application. Applicants' arguments are set forth on the attached five pages 
(numbered 2-6). For simplicity, Applicants have primarily focused the arguments on pending 
independent claim 1. Similar arguments apply to all other independent claims. By setting forth 
these clear grounds for error, Applicants do not assert that these are the only errors that the 
Examiner has made, nor do Applicants waive any arguments that may be asserted in a Appeal 
Brief. 

No amendments are being made with this request. This request is being filed with a 
Notice of Appeal. The review is requested for the reasons set forth below. 
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STATUS OF CLAIMS 

Claims 1-43 are on appeal in this case. Claims 1-15, 17-18, 21-25, 29-43 stand rejected 
under 35 U.S.C. 102(e) as being anticipated by Moussa et al. (USPN 6,742,03) in view of 
eekim.com (CGI Programming slides, 1996) ("Eeikim"). Claims 16, 19-20, 26-28 stand rejected 
under 35 U.S.C. 103(a) as being unpatentable over Moussa et al. (USPN 6,742,043). 



SUMMARY OF THE INVENTION 

The present invention relates generally to techniques for causing a web resource, such as 
a web page, to be more quickly displayed on a browser. The invention may be best understood 
in reference to FIG. 4 of the present application: 
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As described on pp. 5-6 of the present application, at 404, a request for web resource 230 
is sent from a remote client 202 to an IP address that the remote client browser associates with 
the web server 204. At 408, the server 204 sends an initial response to the client 202 before the 
request is processed . Typically, this initial response is or includes an Initiate Page Rendering 
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Message (IPR message). The IPR message is not necessarily dependent upon the content or 
nature of the request. In some embodiments, the IPR message is generic such that the same IPR 
message is sent each time the server receives a request, regardless of the contents of each 
individual request. In this manner, a generic response independent of the request is sent to the 
client 202 to initiate the page rendering process at client 202 even before the initial request is 
processed. 

The Moussa reference (U.S. Patent No. 6 .742,043) 

Moussa describes a proxy server that reformats web content in a particular way under 
certain conditions as determined by the operator of the proxy server. 1 The proxy server retrieves 
web content requested by a client, reformats it into a suitable format for the requesting client, and 
then forwards the reformatted web content to the requesting client. 

With respect to Moussa, the Examiner primarily relies on col. In. 35-65, which reads as 
follows: 

HTML rewriter software 11 also functions to reduce or eliminate a dead time 
("perceived latency") sometimes experienced by a user of client 2. The browser in client 2 
can start to render a web page involving an image if the browser has size information for 
the image. If the browser has size information for the image, then the browser can begin 
to lay out the background page leaving a blank of the appropriate size for the image data 
yet to arrive. ...To avoid this perceived latency at the client, WebTV server 6 stores size 
information relating to the image in cache 8. When client 2 requests a web page 
involving an image, WebTV server 6 retrieves the size information from its cache, 
rewrites the HTML of the web page to include the size information, and then relays the 
HTML on to client 2. The browser in client 2 can therefore begin to render the web page 
using the size information for any images on the web page when it receives the HTML for 
the background page. The browser does not have to wait until it deciphers the HTML of 
the background page, identifies the image tag, issues a request for the image data 
identified by the image tag, and receives the actual image data with the size information. 
The size information is received along with the original HTML. The result of the 
rewriting of the HTML therefore results in a reduction in "perceived latency" at client 2. 

The Examiner also relies on col. 10. 11. 45-60, which similarly states: 

To eliminate this "perceived latency" in the rendering of the background 
page, tokenizer CRM 403 inserts the size information into the HTML before the 
HTML is passed back to client 102. 
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The Eekim Reference (Eekim.com, CGI Programming slides, 1996 ) 

Eekim is a two page document cited by the Examiner that describes the basic format of a 
standard hypertext protocol (HTTP) response. Eekim describes the HTTP response itself as 
including a header that instructs the browser as to the type of content carried by the remainder of 
the response. On pg. 2, Eekim states that after processing a client request, the server outputs a 
response message that includes: (1) headers carrying the MIME Type, (2) a blank line, and (3) 
the requested data (content). 

Claim 1 

Applicant claim 1 reads as follows: 

A method for computer networking, comprising: 

receiving a request for a web resource from a remote client; 

prior to processing the request, sending a message to initiate a page rendering 

process at the remote client, wherein content of the message is independent of the 

request; 

processing the request to produce a response; 
sending the response to the client 

Contrary to the Examiner's assertions, Moussa in view of Eekim fails to teach or suggest, prior to 

processing the request, sending a message to initiate a page rendering process at a remote client, 

as recited by Applicants' claim 1. Furthermore, contrary to the Examiner's assertions, Moussa in 

view of Eekim fails to teach or suggest wherein content of the message is independent of the 

request , as further recited by Applicants' claim 1. 

The Examiner's argument can be best understood by viewing the Advisory Action mailed 

July 22, 2005. In the Advisory Action, the Examiner referred to Moussa and stated: 

[W]hat is requested isn 't the metadata but the actual content The client would 
first request a page/image, the server side initially sends the size information of the 
requested data to allow for initial rendering of the webpage contents on the client side, 
not that the actual requested contents have not yet arrived. Thus the message returned is 
independent of the request 

Thus, in rejecting Applicant's claims, the Examiner is arguing that the image size information 
returned by the Moussa proxy server is independent of the request. This assertion is clearly 
erroneous. The image size information returned by Moussa is directly a function of the particular 
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image requested by the client. As quoted above, Moussa makes very clear that, when client 2 
requests a web page involving an image, WebTV server 6 retrieves the size information for that 
image from its cache, rewrites the HTML of the web page to include the size information, and 
then relays the HTML on to client 2. Thus, Moussa makes clear that, for a given client request, 
the request must be processed to first determine the requested image, and then size information 
for that particular image is returned to the client to reduce latency. If the client requests a 
different image, then clearly different image size information is returned. Moreover, Moussa 
specifically states that the image size information is inserted into the HTMLof the requested web 
page that is returned to the client. 

Eekim adds nothing to address the deficiencies of Moussa. As discussed above, Eekim 
merely describes the format of a standard HTTP response itself includes as including a header 
that instructs the browser as to the type of content carried by the remainder of that same response. 

In summary, the Examiner is clearly erroneous on at least two counts. First, the 
Examiner's reliance and characterization of Moussa as returning a request that is independent of 
the request is incorrect. Second, the Examiner is also incorrect in characterizing the Moussa 
proxy server as sending a message to initiate a page rendering process at the client prior to 
processing the request . Although the image size information returned by the Moussa proxy 
server is indeed different from the image, this image size information is nevertheless directly 
related to and a direct function of the particular the image contained in the requested web page 
requested. Moreover, this information can only be determined by processing the specific request 
issued by the client. It simply cannot be said that the image size information provided by the 
Moussa proxy server is provided prior to processing the client's request and is independent of 
that request. It should be clearly understood that the image size information provided by the 
Moussa proxy server varies depending on the web page being requested, and the image size 
information is actually inserted within that requested web page. 

For purposes of this Pre- Appeal Brief Request For Review, Applicants again stress the 
fact that Moussa in view of Eekim lacks any teaching or suggestion of a method comprising, 
prior to processing a request from a client, sending a message to initiate a page rendering process 
at the remote client, wherein content of the message is independent of the request, as required by 



-5- 



Application Number 09/975,282 
Pre- Appeal Brief Request for Review 



Applicants' claim 1. Applicants request a review and a panel decision that promptly resolves the 
issues in Applicants' favor and eliminates the need for an Appellate Brief. 

Please charge any additional fees or credit any overpayment to deposit account number 
50-1778. The Examiner is invited to telephone the below-signed attorney to discuss this 
application. 

Date: By: 



SHUMAXER & SIEFFERT, P.A. 
8425 Seasons Parkway, Suite 105 




Name: Kent J. Sieffert 
Reg. No.: 41,312 



St. Paul, Minnesota 55125 
Telephone: 651.735.1100 
Facsimile: 651.735.1102 
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